Towards Trust in Digital Rights Management Systems

Digital transactions are usually based on mutual trust. In case of DRM (Digital Rights Management) this initial trust is missing on both sides. Neither do the content providers trust their clients – therefore DRM was established. Nor do the clients trust the content providers and react with not using these systems. The release of an open DRM standard by the Open Mobile Alliance (OMA) was a first step to increase the trustworthiness of DRM. But from the content providers’ perspective a secure implementation for PC Platforms was missing. Especially the mechanisms to obfuscate and install the device private key which is the security anchor were not established there. This paper shows a software solution for that. A more riskless way to solve this problem is the involvement of Trusted Computing which is also shown by the authors. Finally the authors claim the necessity not to leave the users’ security behind. 1 Motivation and Introduction Digital Rights Management Systems (DRMS) were developed to enforce the rights of the content providers but the ultimate success is still missing [1]. The reason for it is obvious. Singh et al [2] accurately expressed it: “DRM policies were driven by lack of trust and treated everyone like criminals”. According to [3] successful digital transactions always depend on security, trust and benefit. In order to increase the acceptance of the DRMS there definitely have to be improvements in these areas. As commercial operations always are multilateral [comp. 4], these changes have to be made on both consumers and providers side. Therefore we introduce in chapter 2 an open DRM standard which was released by the Open Mobile Alliance (OMA) [5]. In chapter 3 we present our proposal for a mechanism which uses obfuscation techniques to protect the device private key which is the security anchor of the OMA DRM agent. Another attempt to build a trustworthy and secure OMA DRM agent is Trusted Computing which is discussed in chapter 4. Afterwards we argue how these mechanisms have the ability to improve the trustworthiness of the providers. We also give recommendations where there have to be further improvements. 2 Jürgen Nützel and Anja Beyer 2 Digital Rights Management of OMA The Open Mobile Alliance (OMA) [5] is an organization which develops open standards to increase the interoperability of mobile services. Nearly all mobile operators and device manufacturers are members of OMA. One of OMA’s standardization activities focuses Digital Rights Management (DRM). The authors are of the opinion that OMA will become a leading role in the DRM business because all the leading mobile operators and mobile hardware manufactures support this standard. The main goal of any DRM [6] solution is the enforcement of permissions and constraints associated with the content. The main threat comes from unauthorized access to protected content beyond the grants of the associated rights objects. OMA DRM V1.0 only provides three simple protection schemes: forward-lock, combined delivery and separate delivery. See [7] for more information. It becomes obvious that these simple protection schemes do not fulfill the requirements of a second generation DRMS. Therefore OMA developed a second release. 2.1 The DRM Reference Model and OMA DRM V2.0 The first release of the DRM specification lacks the complete security necessary for a robust, end-to-end DRMS that enables a secure distribution, the authentication of devices, revocation and other aspects like a domain concept [9]. V2.0 which is the focus of this paper addresses these missing aspects. In [10] a DRM reference model was introduced which well describes the fundamental structure and functions of most of the OMA DRM V2.0. The three major components are the content server, the rights issuer (RI) and the DRM agent. According to this reference model (see fig. 1) the download and usage of content files is proceeded as follows. Fig. 1 DRM reference model with usage counter and device key pair for device identification. Before a download can start the content server has to prepare the encrypted content. In the same manner as every modern DRMS, the content is packaged in a content (DCF) DRM Agent Decoder Content Server Rights Issuer’s (RI) usage counter 1st: Download 3rd: RO Requ est 2nd 4th: RO Transfer 5th 7th 7th Rights Object (RO) cek usage rights r CEK Consumer’s Device with DRM Agent 3rd & 6th Device Public Key Before: Key exchange Device Private Key Towards Trust in Digital Rights Management Systems 3 secure container (DCF). The content is encrypted with a symmetric content encryption key (CEK). The content server adds additional data like unique content ID and the address of the RI to the content package and hands the applied CEKs (or a seed information to retrieve the keys from) over to the RI. The RI stores the CEKs and provides them on request (3 step in fig. 1) together with the appropriate usage rights in form of a rights object (RO). This is an XML document, expressing the permissions and constraints (using ODRL 2.1 [8]) associated with the content and also contains the CEK. Therefore the content cannot be used without the appropriate RO. All DRM agents have a unique device key pair and a certificate. The certificate (not shown in fig. 1) includes information such as issuer, device type, software version, serial numbers, etc. This allows the RI to securely authenticate a user’s device. The certificate with the device public key is transferred during the rights object acquisition protocol (ROAP, 3 and 4 step) from the DRM agent to the RI. In [10, p. 82] the DRM agent is described as “...the real nerve center of the DRM system.” It enables the user to exercise his rights, to render the content and it organizes the communication with the content and the RI [10, p. 79ff]. Figure 1 also shows a typical sequence for a DRM system: In the first step the user receives a content package either by downloading it from a content server or from another user (superdistribution). In order to render it, the DRM agent needs an appropriate RO. If no local stored RO was found the DRM agent sends a RO request to the RI (3 step). The request includes the identity of the device (by sending the device certificate with the device public key) and the content ID from the content package (DCF). Before the forth step might happen a financial transaction is initiated. Afterwards, the RI creates the RO containing usage rights and CEK. Before delivering the RO in step 4 to the client device, sensitive parts like the CEK are additionally encrypted using the symmetric REK (right object encryption key). The RO is cryptographically bound to the target DRM agent. This is done by using the device public key which encrypts the REK. This ensures that only the target DRM agent with corresponding device private key can access the RO and thus the content. The DRM agent is able (in step 5 und 6) to access the CEK using the device private key (and the REK). Depending on the usage counters and the usage rights (“play three times”) the content will be decrypted and rendered in the decoder. Like the CEK the device private key may not leave the trusted environment of the DRM agent due to being it’s security anchor. If it becomes disclosed, the user will be able to decrypt every content package without a proper RO. These are the most important aspects of the OMA DRM security model. Further aspects refer to state of the RO (e.g. remaining number of play-back or usage time) and the time on the user’s device which may not be modified by the user. An unauthorized modification of the play-back counters or the device time has to be prevented as well. In chapter 3 we introduce our approach to obfuscate this key on open/insecure platforms like Linux and Windows PC’s. In chapter 4 we show how Trusted Computing makes risky software obfuscation obsolete. This will enable a trustworthy OMA DRM even on complete open platforms like Linux. 4 Jürgen Nützel and Anja Beyer 3 Software Implementation of OMA DRM Agents An attack on the CEK could be possible if the REK in the ROs could be deciphered if the device private key becomes obvious, therefore the device private key has to be kept secret in the trusted environment of the DRM agent. A second possible threat is the loss of the device authentication. The complete security of the communication between the RI and the DRM agent relies on the device key pair. If a private key gets “lost” an attacker could implement (according to the open OMA protocols) a corrupt DRM agent which simply decrypts the DCF instead of rendering it. The RI can react (if it is detected) on this threat only by the revocation of this corrupted device (identified by the device certificate) or even by the revocation of all devices of this device type. After the revocation the revoked device is no longer able to receive valid ROs. The developer of the agent’s software gets seriously into trouble with the revocation of DRM agents [11]. 3.1 Obfuscation of the Key Store Mobile devices are the main focus of OMA DRM. Nevertheless, there is a great interest in the industry to port the DRM agent also to other platforms, especially to Windows XP. The problem is that the Windows XP operating system does not support trusted storage facilities to hide the device private key. In chapter 4 we introduce an OMA DRM implementation based upon the efforts of the TCG (Trusted Computing Group) [12]. But currently Trusted Computing even with Windows Vista [13] comes very slowly onto Windows platforms. Therefore we have to think about less secure solutions based upon software obfuscation techniques. Such obfuscated software solutions have to solve two goals: Fig. 2 Hiding and device binding of the device private key using hardware parameters. Hiding and device binding: The device private key must not become visible and must not be transferred to any other device (PC). The following procedure is our proposal for a solution to this problem. Our approach is to store the private key encrypted in a key store file (see figure 2). The encryption is done by a randomly generated symmetric key (RK). RK will be stored also in the key store. The RK will be encrypted by symmetric keys (the hardware keys, HWK), which will be derived directly from several hardware (or system) parameters like MAC address, hard disc and graphic card IDs and others. To avoid the loss of the key store after the replacement of the hard disk, the RK has to be encrypted several times with different Key Store File random key Client Device with (n=4) different hardware parameters: p1,p2,p3,p4 dprivk random key random key random key HWK1(p2,p3,p4):